The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
Internet Protocol Multimedia Subsystem (IMS) is a subsystem supporting IP multimedia service, and is proposed by the 3rd Generation Partnership Project (3GPP) in Revision 5 (R5). The main feature of the IMS is using of Session Initiation Protocol (SIP) and the supports of access independence. The IMS is a multimedia control or call control platform in Packet-Switched (PS) domain. The IMS supports session multimedia services and non-session multimedia services, and provides a common service platform for the future multimedia application.
The emergency call is a special voice service function in mobile telecommunication system. Even in the case that call barring is set in a mobile terminal and that Subscriber Identity Module (SIM) is not inserted in the mobile terminal, when a user dials some special number such as 110, 119 or 120, the call will be forwarded to the corresponding Public Safety Answering Point (PSAP) such as police stations, fire departments and first aid centers as long as the mobile terminal is located in the area covered by the mobile network. Therefore, emergency aid service can be provided to users round the clock. Operations of the entire system are implemented jointly by telecom operators, fire departments, hospitals and the like.
Conventionally, the emergency call is implemented in the Circuit-Switched (CS) domain. While more and more networks adopt the IP technology, the PS domain begins to support the emergency call service gradually, and use the IMS system to control call signaling for the emergency session. The emergency call service provided by the IMS domain is called IMS Emergency Call, for short, IMS-EMER.
Subscriber identity in the IMS system is called IMS Public Identity (IMPU), and the IMPU is used when an IMS user requests to communicate with others. The IMPU is in SIP Uniform Resource Identifier (SIP URI) format or in Telephone Uniform Resource Identifier (TEL URI) format. The SIP URI takes the form of sip: user@domain, where the “user” stands for user name and the “domain” stands for domain name. The TEL URI takes the form of tel: number, where the “number” is generally international standard telephone number, i.e., E.164 number.
FIG. 1 is a flowchart of a conventional method for emergency call in an IMS domain. The method is described in further detail below.
In Block 101, a User Equipment (UE) sends an emergency call request message to a proxy call session control function entity (P-CSCF), the emergency call message contains an emergency call identifier. Further, the P-Preferred-Identity header of the emergency call request message contains an IMPU in TEL URI format or in SIP URI format.
In Block 102, the P-CSSF receives the emergency call request message, then, the P-CSCF checks whether the IMPU of the UE contained in the emergency call request message is in the TEL URI format or in the SIP URI format. If the IMPU is in the TEL URI format, Block 103 is performed. If the IMPU is in the SIP URI format, Block 105 is performed.
In Block 103, the P-CSCF checks whether the IMPU in the TEL URI format is valid. The IMPU in the TEL URI format is contained in the emergency call request message. If the IMPU in the TEL URI format is valid, Block 104 is performed; if the IMPU in the TEL URI format is not valid, the emergency call fails, and the process is terminated.
In Block 104, the P-CSCF generates a P-Asserted-Identity header in the emergency call request message, and the IMPU in the TEL URI format is contained in the P-Asserted-Identity header. Meanwhile, the P-CSCF deletes the P-Preferred-Identity header from the emergency call request message, and then sends the emergency call request message to an Emergency-CSCF (E-CSCF), and Block 106 is performed.
In Block 105, the P-CSCF generates a P-Asserted-Identity header in the emergency call request message, and generates an IMPU in the TEL URI format according to the IMPU in the SIP URI format contained in the emergency call request message. The IMPU in the TEL URI format and the IMPU in the SIP URI format are both contained in the P-Asserted-Identity header. Meanwhile, the P-CSCF deletes the P-Preferred-Identity header from the emergency call request message, and then sends the emergency call request message to the E-CSCF.
In Block 106, the E-CSCF forwards the emergency call request message to PSAP after receives the emergency call request message from the P-CSCF.
In Block 107, the PSAP receives the emergency call request message, and saves a UE calling identifier contained in the emergency call request message, i.e., saves the IMPU in the TEL URI format in the P-Asserted-Identity header, or saves the IMPU in the TEL URI format and the IMPU in the SIP URI format in the P-Asserted-Identity header.
When the PSAP determines to initiate an emergency callback to the UE, if the PSAP detects that the PSAP is located in the CS domain, the PSAP sends an emergency callback request message to the UE according to the IMPU in the TEL URI format, the emergency callback request message is sent to the UE via S-CSCF and P-CSCF in turn; if the PSAP detects that the PSAP is located in the PS domain, the PSAP checks whether the PSAP saves the IMPU in the SIP URI format. If the PSAP saves the IMPU in the SIP URI format, the PSAP sends the emergency callback request message to the UE via S-CSCF and P-CSCF in turn according to the IMPU in the SIP URI format. If the PSAP does not save the IMPU in the SIP URI format, the PSAP performs telephone number mapping (ENUM) function to find the IMPU in the SIP URI format according to the IMPU in the TEL URI format saved in the PSAP, and then sends the emergency callback request message to the UE via S-CSCF and P-CSCF in turn according to the IMPU in the SIP URI format.